There is both UI work to better align the space in this panel and UX for the information hierarchy.

From user feedback "network header tab is confusing", "a lot of information in a very compressed space – should be redone", "easy selecting and copy-pasting of request/response headers (for example: right-click header name and have the option to copy the name, value or name and value)."

Constraints that I'd like to throw in:

• Consistent raw/pretty split/toggles for all data types (headers, params, payloads, cookies)
• Consistent search in all important data types
• Obvious copy/save for whole raw/pretty sections or specific entries and their parts (mostly name/value)
• Maybe: States for pending request, streamed request/response

Questions:

• Would it make sense to move away from tabs to one accordion holding more/all sections?

Would it make sense to move away from tabs to one accordion holding more/all sections?

Many sections have sub-sections, so we'd end up with like 10 accordion items which is a bit much. And for sections like Messages (websocket) it's useful to have the full sidebar's height available.

Consistent raw/pretty split/toggles for all data types (headers, params, payloads, cookies)

I notice that the Debugger when for a standard checkbox (in the Event Listener Breakpoints accordion header). We could use that, or make a smaller toggle control (the current one is rather big) and use it in Debugger too.

Personally for Headers I'd be happier with a single "Raw Headers" toggle (next to "Filter Headers") that affects all sections.

Maybe: States for pending request, streamed request/response

Yes please! It's hard to figure out that a request is pending just by looking at the table row, and you're left wondering if something is broken when the details are blank.

And for sections like Messages (websocket) it's useful to have the full sidebar's height available.

Agreed, beyond WS, preview, formatted payloads and timings work better with more space. Security could link to the cert viewer or inline it.

To simplify the tabs, Cookies and Params could be rolled into the main panel. They often end up empty as well.

Related, Honza and I discussed why WS' Messages could not be shown in Response.

A related UX bug, improving the summary view for cached resources: https://bugzilla.mozilla.org/show_bug.cgi?id=1338065

Also to add to the list of suggestions from honza above

• Can we move the filter headers to the top to be consistent with the other panels?

Can we move the filter headers to the top to be consistent with the other panels?

A small toolbar with "Filter Headers" and a toggle for "Raw Headers" would be great. It'd be consistent with the Messages tab, or with what we have in the Inspector for Computed styles, for instance:

One difficulty is that those controls wouldn't affect the first block of information with the URL, Status, HTTP version etc. That could make the top placement a bit awkward.

Great, I really like these ideas (search box within a toolbar at the top)
Created a bug for it: https://bugzilla.mozilla.org/show_bug.cgi?id=1617167

Honza

Great, I really these ideas (search box within a toolbar at the top)

I shared @fvsch's concern on how it doesn't search through the first part.

Maybe we can find a consistent toolbar that allows filter/copy/pretty-raw-toggle?

I found Paw last week and found its UI for inspection nice and clean:

Splits data in Info, Request (Headers, Formatted, Raw) and Response (Headers, Formatted, Raw)

Prev/Next buttons in toolbar are nice affordance for navigating between ordered requests (often in REST and page load):

Summarized request/response meta data links to the Request/Response tabs:

Raw tab shows full HTTP (with basic highlighting for headers):

Share button to export & upload to online viewer:

I found Paw last week and found its UI for inspection nice and clean:

I can't open the Paw link (or is it suppose to be a link?)

I can't open the Paw link (or is it suppose to be a link?)

Fixed. It is on paw.cloud :).

Updating priority as @bomsy will be starting on this soon.

@violasong fyi, we had some discussion today for some mock ups I made: https://www.figma.com/file/cf8pMDTvi64HWzRhQWdMnO/DevTools-Network-Details-Pane?node-id=32%3A2

I'm working on a mockup but here are some initial thoughts:

Could we hide the Cookies/Params/etc tabs if they're empty, or could this be confusing?

Paw is a great find! Nice example of Mac native patterns.

For copying, there are a couple things we could try:

• When selecting a row, Cmd/Ctrl-C should copy both name/value
• Double-clicking a name or value should select that whole string (currently the selection stops at any hypens, so for an example like this, it's hard to grab the whole name or value)
• Copy button that shows up on hover at the end of each row - maybe a bit much. Could be batched up with the info button which should be on the right side.
• Raw header sections could have an always visible copy button

Some little consistency issues that could be fixed:

• Accordion header text can currently be selected. Also, it has a blue background on hover.

States for pending request, streamed request/response

Curious about this, but need to learn more. What does this look like in other places?

Another thought I had - in the sidebar, Request URL, Method, and Status Code are a tad redundant with what would hopefully be showing in the table view. (Especially if we try something like hiding more of the other columns when the sidebar is open.)

I noticed Safari does this nice color coding. Does categorizing it this way make sense?

Ah, I looked at the Safari screenshot more closely and realized it just has more redundant info that's separated out. I like the visual styling though.

Another thought I had - in the sidebar, Request URL, Method, and Status Code are a tad redundant with what would hopefully be showing in the table view. (Especially if we try something like hiding more of the other columns when the sidebar is open.)

I think I know what you mean. With the current table there is some redundance, but only "some" as the columns are often squished so small that the information can't really be seen. When we get around to minimize the table's sidebar-open mode to a single column this should not be an issue though, right?

States for pending request, streamed request/response

Pending requests will only have request parts (headers, payload, cookies, etc), but no response. Same for blocked requests btw. Streamed responses have some response parts and others are still coming in in chunks. There are also streamed requests, for multipart uploads; which have chunk request data in multiple parts.

Ah, I looked at the Safari screenshot more closely and realized it just has more redundant info that's separated out. I like the visual styling though.

As usual, I don't understand Safari's color/icon choices ;) . But as long as things are readable and copy-able we are good. It feels similar to Paw's information hierarchy, which highlights key aspects in slightly bolder form and then just lists out the rest.

With the current table there is some redundance, but only "some" as the columns are often squished so small that the information can't really be seen. When we get around to minimize the table's sidebar-open mode to a single column this should not be an issue though, right?

True, especially if only show the filename. But I wonder if we might want to keep the status/method in the table.

Pending requests will only have request parts (headers, payload, cookies, etc), but no response. Same for blocked requests btw. Streamed responses have some response parts and others are still coming in in chunks. There are also streamed requests, for multipart uploads; which have chunk request data in multiple parts.

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

True, especially if only show the filename. But I wonder if we might want to keep the status/method in the table.

This reminds of of an idea I liked UX table, Row to Details. It compresses additional details into the remaining row.

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

Yes, showing missing data as blank state (vs just not having the fields) makes sense.

Using phases from Resource Timing to map out which data gets available over time:

1. requestStart: Request headers available (for many failed/blocked requests, this is we ever have)
2. multipart/form-data requests (only important for file uploads): Chunked data are being added as they are sent
3. responseStart: Response headers available
4. responseStart to responseEnd: Response data chunks (and additional headers) available as they are received
5. responsEnd: All data available

@janodvarko did I miss a state?

Content for the summarized section

* Single-line summaries for
  * Request: Method + Host + Path → Link to _Request_ tab
  * Response: HTTP Code → Link to _Request_ tab
  * HTTP/TLS Version → Link to _Security_
  * Size / Transferred Size + Time to Load → Link to _Timing_
  * Blocked Cookies? → Link to _Cookies_
  * Referrer Policy

Some questions about this:

• What do you mean by "Link to Request tab"? (Different from the Request Headers section?)
• Should we also have a link to Cookies when it isn't a blocked request?
• Do we still want to show Address?

At first I was thinking of a menu-like UI like this

But the sections that these would link to don't seem obviously connected to me. It might be better to name them, e.g.

I see - so, assuming we can differentiate whether some data is either missing or waiting, we could indicate that.

Yes, showing missing data as blank state (vs just not having the fields) makes sense.

@janodvarko did I miss a state?

I think that we can see it a bit more precisely as follows:
(but, the impact on the UI might be minimal)

• Request Start - Request headers available, POST data, request cookies, stack trace
• Sending POST Data - might take a time in case of big upload data
• Waiting for Response - might take a time if the server is slow. The server might be also in error state and no responsive (aka timeout)- in which case we might get no more data
• Response start - getting response headers, response cookies,
• Receiving data (aka downloading) Response data chunks (and additional headers) available as they are received
• Response end (or Request closed) - All data available now, no more data should be expected.

More info in HAR spec: http://janodvarko.cz/blog/har-12-spec/#timings

One more note. Request HTTP status is using a styled number in the first column

We can reuse the same style in the Headers panel.

Honza

Related, I just checked out Safari's Network details pane which has some related ideas to grouping and labels (It is a bit hidden in Sources, which seems a nice touch, to have that information available in other panels; but kind of hard to discover):

• URL is broken down into its parts, making bits easier to copy/read and better represents concepts like REST. Maybe we could have an expandable section for that in the tree? Could we add IP there as well?
• Initiator line is called out
• Sizes are broken down into encoded, decoded (size in browser memory) and transferred. Compressed section is nice with the algorithm and the ratio – but why is not with the sizes, like 2.4kb (2.5x / gzip)?.

@violasong looks great.

@bomsy looking at Victoria's work, it doesn't seem like we'd want to use the tree component for that. Or do you see that we should customize it to present data like that?

What do you mean by "Link to Request tab"? (Different from the Request Headers section?)

Sorry, the Params payload tab, which should be called Request for consistency.

Should we also have a link to Cookies when it isn't a blocked request?

Not sure where I would put this, so no.

Do we still want to show Address?

It would be important to know which server is resolved for some requests. See my analysis for Safari – maybe it fits with additional URL data.

But the sections that these would link to don't seem obviously connected to me. It might be better to name them, e.g.

I like the option as well. Maybe they could appear on hover to reduce UI density?

Regarding the labels, in the application panel design, we had more muted labels. Maybe we can try those out for comparison.

I like the option as well. Maybe they could appear on hover to reduce UI density?

That seems good, although maybe we want something there to encourage users to use the more contextual UI instead of looking through the tabs?

Regarding the labels, in the application panel design, we had more muted labels. Maybe we can try those out for comparison.

That subtler look could work if we keep the labels short to allow for more spacing, like this:

It wouldn't match the request/response headers though.

(Figma for all mockups so far)

• Blocked Cookies? → Link to Cookies

Should we also have a link to Cookies when it isn't a blocked request?

Not sure where I would put this, so no.

What should show up in the summary for Blocked Cookies?

Ideas:

Expand arrow on the URL opens to show query string params

Some syntax coloring on the URL (this doesn't look great, but maybe something similar could work

Idea:

More separation for warning/error messages in Header Summary

Or should we just put it at the top?

Idea: In header sections, show info (MDN link) and copy button on hover

Idea: All the above, with Response headers in blue sans-serif 12px labels + black monospace 11px values.

Same as above, except with gray labels.

Thanks Victoria for the mockups, it looks really great!

• Expandable URL - to show URL params. We can also play with showing individual URL parts (domain, path, etc.)
• Color syntax for collapsed URL - awesome idea!
• Using block layout for the summary info is great (I don't think it's a problem that headers use different layout)
• The tracking protection notification message at the top is nice. We could use this concept for other messages as well (more info about request error state, etc)

Questions:

• What's supposed to be in the Resend dropdown? I can think of "Edit and Resend" and "Resend", is that it?
• What's suppoed to be in the Block dropdown?

Honza

Idea: All the above, with Response headers in blue sans-serif 12px labels + black monospace 11px values.

@violasong the smaller font seems also good to save space for longer output. Blue is also good since the summary section already has a grid layout to differentiate visually.

It just occurred to me that you mentioned another example for this, how the Debugger sizes those lines. Is that sizing/spacing aligned? It seems like it:

The tracking protection notification message at the top is nice. We could use this concept for other messages as well (more info about request error state, etc)

What other errors did you have in mind, @janodvarko?

An alternative to the error could be adding a line with a warning in-line with the tracking category.

Referrer:         no-referrer-its-referer
Content Blocking: Tracking Content
                  🛡 Be aware that cookies or content for this URL could be blocked. (?)`

WDYT, @violasong ?

Color syntax for collapsed URL - awesome idea!

@violasong I like the idea. It does make it a bit more readable. I am not sure which parts we should highlight; as use cases vary on what's important to users. Have you seen an example of that anywhere else?

What's supposed to be in the Resend dropdown? I can think of "Edit and Resend" and "Resend", is that it?

Yes, that was my proposal, making sure we are exposing more options from the context meny in the toolbar. @violasong another idea would be an "Edit" button and a "Resend" button; where Edit implies that it would be send again anyways. So we avoid the dropdown.

What's suppoed to be in the Block dropdown?

"Block URL" is very blunt atm. I proposed this as we can expose more options. "Block Domain" and "Block Path" could be added here. To simplify, it is probably easier to use the blocking icon from the network toolbar and avoid the dropdown. If users want to fine-tune, the blocking sidepanel will open automatically anyways and they can edit the URL down to what they need.

What other errors did you have in mind, @janodvarko?

I like the idea to use the notification box as a generic way to show any error/warning/info that's worth of user attention.

• Blocked requests - blocked reason, Blocked Extension (this info is hard to read from a column).
• Classification flag - cryptoming/tracking/fingerpriting
• Tracking protection - Detailed explanation

Honza

Updated color syntax for collapsed URL:

Changed magenta to gray which I think works better, and added in the filter bar.

@violasong I like the idea. It does make it a bit more readable. I am not sure which parts we should highlight; as use cases vary on what's important to users. Have you seen an example of that anywhere else?

I don't think I've seen this elsewhere, though the grayed out https:// is like Firefox's URL bar. The idea I had is that the blue parts correlate to the blue keys when expanded.

Expandable URL - to show URL params. We can also play with showing individual URL parts (domain, path, etc.)

So something like this?

Mockup with:

• Harald's last suggestion for error message. This de-emphasizes the error and makes it more a part of the summary rather than an extra section. Sounds like that's what we want?
• A more typically-sized URL with no params, shown in the style of the query param examples
• Smaller toggle for switching to raw

@violasong looks really nice! Makes me want to click around and play with it.

One thing I am not sure about is the shortened labels ("Blocking" is less descriptive than "Content Blocking") and other languages will vary in length as well. What's the strategy to make this responsive and overflow in sensible ways?

Harald's last suggestion for error message. This de-emphasizes the error and makes it more a part of the summary rather than an extra section. Sounds like that's what we want?

A more typically-sized URL with no params, shown in the style of the query param examples

Should this URL be limited in lines, using line-clamp?

FYI, the parts of the URL that we should show are all listed in https://developer.mozilla.org/en-US/docs/Web/API/URL .

Smaller toggle for switching to raw

Perfect size!

Just to get consensus (I am a fan of hover menus), is the idea from #116 (comment) accepted? @bomsy @janodvarko

One thing I am not sure about is the shortened labels ("Blocking" is less descriptive than "Content Blocking") and other languages will vary in length as well. What's the strategy to make this responsive and overflow in sensible ways?

Ah, I see. I'll look at this some more. Here's one thing we can do with the alignment, though we don't do this anywhere else.

Should this URL be limited in lines, using line-clamp?

I thought we were saying that the full URL is important here, as this is the only place to see the whole thing (besides the query string, but that's an extra step and kind of different).

I thought we were saying that the full URL is important here, as this is the only place to see the whole thing (besides the query string, but that's an extra step and kind of different).

Right, makes sense. Might also work if we expand it to a full URL when the user expands this section. If we do a proper line-break (not like now), 1000+ character URLs will take up a lot of space.

(Example of word-wrap in VS Code and in our current URL preview:
)

Just to get consensus (I am a fan of hover menus), is the idea from #116 (comment) accepted?

@digitarald I like that idea, out of curiosity how would it look for headers that have the warning icons (set-Cookie in this example)?

Might also work if we expand it to a full URL when the user expands this section. If we do a proper line-break (not like now), 1000+ character URLs will take up a lot of space.

I see what you mean, there needs to be some level of truncation at some point :D

This could work, though the expanded query string part could end up being pretty massive

@digitarald I like that idea, out of curiosity how would it look for headers that have the warning icons (set-Cookie in this example)?

Maybe @violasong has ideas how some icons are always on and don't need hover. Otherwise we could show errors like we do them inline in the general section?

This could work, though the expanded query string part could end up being pretty massive

As it's expanded optionally, that seems acceptable.

I like that idea, out of curiosity how would it look for headers that have the warning icons (set-Cookie in this example)?

Good point. I realized I also didn't work out how the hovering would work on a long row.

One quick idea: buttons float on top on hover, like in Copy Rules:

Hm, right after posting this I realized it's probably too much fanciness as it obscures basic copy paste, like if someone just wanted to grab the time part of that timestamp.

So the other option is there's just an area on the right side saved for the icons, and the text would wrap before getting there.

One quick idea: buttons float on top on hover, like in Copy Rules:

I like that. One caveat to test during implementation is how hover-enabled buttons interact with selecting text portions.

For the URL params when there are many:

This could work, though the expanded query string part could end up being pretty massive

One option is to truncate and, rather than expand, add a button that sends the user to the "Params" tab where we already parse and display the URL parameters.

@violasong One aspect to think about is long header names and how to align the values:

Just for reference, leaving this example for a super-long URLs that makes the URL preview take over the whole above the fold space for the panel; so we can test it against the new bug:

One aspect to think about is long header names and how to align the values:

Ah, this screenshot is unfortunate; makes me think we should full-length wrap the values.

For super long URLs, an idea I just talked about with @nchevobbe regarding the Send Request Figma was limiting it to a certain number of rows (5?), and adding scroll overflow once it goes over.

adding scroll overflow once it goes over.

line-clamp to the rescue.